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applied to the program. Thus, a development is merely a linear sequence of 
transformations applied to the PROGRAM resulting from the previous stage of 
development. Each stage of the development corresponds to the transformation 
of a program treated as a specification into another treated as an 
implementation. Thus, development is an iterative (or sometimes a recursive) 
process of successive refinement in which a specification is gradually 
transformed into an implementation. This implies that the original 
specification of the program is itself a program (so that it can be 
transformed). To be a program, the specification language must have a formal 
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INTRODUCTION 


Much recent work has focused on the Investigation of Program Manipulation Systems 
[1, S, 6, 7, 8, 12, 14, 18] as an alternative programming paradigm In which the 
PROCESSES of design and Implementation are themselves the subject of study. They 
are captured and recorded to provide documentation of the program, the basis for Its 
validation, and the framework within which future maintenance will occur. 

This extension of the conventional programming paradigm to Include the development 
of the program as a computer processable object (In addition to the program) itself Is 
quite profound. It Is comparable to the early recognition that programs could themselves 
be treated as data, enabling computer languages to be developed. Correspondingly, by 
capturing and recording the development processes, a set of tools can be developed to 
use these processes as data. 

Although such tools do not yet exist, It Is easy to foresee some of their capabilities: 
automatically generated, up-to-date, and accurate documentation of the program relating 
the Implementation back to its specification; explication of all the assumptions used 
within the development and Identification of the decisions made therein; validation of an 
Implementation based not on an analysis of the resulting program, but rather upon the 
process by which It was produced; maintenance performed by modifying the development 
process rather than by attempting to modify the optimized program; and automatic 
Instrumentation to test the performance assumptions Implicit In critical design and 
Implementation decisions. 

Before such possibilities can be realized, however, the development process that 
currently exists only within people's heads must be made explicit and recorded. How 
can this be accomplished? 

A key Insight of the Program Manipulation approach Is that transformations provide a 
sufficient basis for the development process. Each development decision can be 
represented as a transformation applied to the program. Thus, a development Is merely a 
linear sequence of transformations applied to the program. (Unfortunately, such linear 
sequences are unintelligible, and like programs, must be structured to be 
undorstandable.) But what programs are the transformations applied to? Since the 
object of the development Is to produce a program, the resulting program is obviously not 
the one to which transformations are applied. 

Instoad, transformations are applied to the PROGRAM resulting from the previous stage 
of development. Each stage of the development corresponds to the transformation of a 
program treated as a specification into another treated as Implementation. Thus, 
development Is an Iterative (and as we will see later, sometimes a recursive) process of 
successive refinement In which a specification is gradually transformed Into an 
Implementation. 

This Implies that the original specification of the program Is Itself a program (so that It 
can be transformed). To be a program, the specification language must have a formal 
semantics (thus precluding pseudo-code types of languages) so that validity of 
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transformations and of the development process Is a meaningful concept. 

Since the motivation of this Program Manipulation approach Is to capture and record 
the development process, It Is essential that the specification be rather directly stated 
and that It be taken as the starting point for the development. Since the intent of a 
specification is to state WHAT Is required, while the intent of an Implementation la to 
state HOW those requirements are to be satisfied with minimal expenditure of computing 
resources, quite different languages for specification and Implementation are Implied. 

This wide disparity between the specification and Implementation language and the 
avoidance of determining HOW requirements should be satisfied within the specification 
suggest to us that the development (embodied as a sequence of transformations) must 
be humanly guided (rather than automatically generated), because such global 
optimization Issues are not well-enough understood to automate (although this view la not 
universally held [4, 6, 17]). Thus, we have constructed an interactive system In which a 
user guides the system by specifying which transformations the system should apply. 
The rest of this report Is a description of the development process In such an Interactive 
Program Manipulation system (as embodied In a prototype we have built) through 
consideration of a simple example. This particular example was chosen to be simple 
enough to cover within this report, yet complex enough to demonstrate the type of 
Issues that arise during development. In addition, only well-known examples were 
considered so that the one chosen did not have to be explained and motivated. 

THE PROBLEM 

Glvon a set of eight Queens, write a program that finds a way of positioning them on 
different squares of a chessboard so that no Queen may capture any other. 

THE FORMAL SPECIFICATION 

Before the development processes of design and Implementation can begin, the 
problem must be expressed In a formal specification. This specification should express 
as much as possible WHAT the program Is to do without expressing HOW it Is to be 
accomplished. The WHAT specification will then be systematically converted Into a HOW 
Implementation during the development process. 

We have developed a formal specification language [2] In which this problem can be 
directly stated. This language allows the definition of a world (Chess) In terms of the 
objects (the chess board, the squares of which It Is composed, the rows and columns, 
the various chess pieces, etc.) of that world, the relationships that may exist among 
those objects (the Immediate adjacency of two squares, the squares that comprise a 
row, pieces occupying a square, etc.), the actions that exist In that world (placing a 
piece on a square, moving a piece, capturing a piece, etc.), the constraints that the 
objects of the world must satisfy (two pieces can't occupy the same square), and the 
rules of Inference within that world (a piece can capture another If It can move to the 
square occupied by that piece, etc.). These declarations define the environment within 
which the program will operate. An initial configuration of the objects In the world can be 
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specified (in this case that the chess board is empty [no pieces are on the board] and 
that eight queens exist). The program portion of the specification then describes either 
the resulting configuration desired (preferred) or the behavior desired (acceptable). 
This latter option Is provided because many real tasks cannot be simply stated In terms 
of a goal state, but rather are more naturally specified in terms of their desired behavior 
(such as a payroll system that periodically issues checks satisfying certain criteria). 
These behavioral specifications would naturally contain as much "resulting configuration" 
description as possible so as to least constrain the ultimate Implementation. As the 
development proceeds, the "resulting configuration" portions are converted Into behavior 
specifications, which are then specialized and optimized. 

For the Eight Queens problem, the formal specification is shown in Figure t. For the 
sake of conciseness and perspicuity the definition of objects, relationships, and actions 
has been suppressed, as has the specification of the initial configuration (which defines 
the structure of the chess board, the fact that no pieces are on any of the squares, and 
the existence of eight queens) and the Inference rule defining Queen-Capture. 

PROGRAMS: 

QUEENS: [LAMBDA ( QUEEN-SET) 

(LOCAL ( BOARD-POSITION) 

(FOR QUEEN IN-SET QUEEN-SETDQ 

(DETERMINE BOARD-POSITION FROM 

(CHESS-BOARD BOARD-POSITION )) 
(ASSERT (PIECE-ON-BOARD QUEEN 

BOARD-POSITION) 


CONSTRAINT: TWO-PIECES-CAN’T-OCCUPY-SAME-SQUARE 

PATTERN: (AND (PIECE-ON-BOARD PIECE#1 BOARD-POSITION) 
(PIECE-ON-BOARD PIECE#2 BOARD-POSITION)) 
PATTERN-VARIABLES: (PIECEtfl PIECES BOARD-POSITION) 

CONSTRAINT: QUEEN-CANT-CAPTURE-ANOTHER-QUEEN 

PATTERN:(AND (PIECE-ON-BOARD QUEEN# 1 BOARD-POSITION#1) 
(PIECE-ON-BOARD QUEEN#2 BOARD-POSITION#2) 
(QUEEN-CAPTURE BOARD-POSTION#1 
BOARD-POSTION#2)) 

PATTERN-VARIABLES: (QUEENS QUEENS BOARD-POSITIONS 

BOARD-POSITIONS) 


Figure 1 


The formal specifications Indicate that subject to two constraints (that two pieces 
can't occupy the same square and that queens cannot be placed so that they can 
capture each other), each queen in the set of (presumably eight) queens Is to be placed 
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somowhere on the chess board. Although this specification Is not the most abstract 
possible (a completely "resulting state" specification is quite straightforward), and 
although a minor Implementation restriction has been Imposed (the requirement of queens 
not capturing each other Is only logically imposed on the resulting solution and need not 
necessarily be true while the solution Is being constructed, as is the case In the formal 
specification of Figure 1), this specification has been chosen to reduce the amount of 
unconventional specification constructs considered in this example. 

THE DEVELOPMENT PLAN 

The development of this specification into an implementation progressed In three main 
phases: explication, reorganization, and representation selection. In the explication 
phase, Implicit structures within the specifications are made explicit and constraints are 
doalt with as early as possible In an attempt to gain an understanding of the algorithmic 
structure Implied by the specification. In the reorganization phase, the sources of 
computational expense are Identified and the program reorganized to mitigate these 
expenses. Representations suitable for the reorganized programs are selected In the 
third phase. 

This phase-based conceptualization of the development process Is not yet part of our 
prototype system and Is Introduced here tc help the reader understand our development 
plans. We theorize that In more complex tasks many cycles of this basic plan occur (It Is 
also clear that the representation selection may precede the reorganization). If so, then 
some structure must exist among these cycles. Such structure, arising partially a priori 
(plan) and partially a posteriori (documentation), represents the explanation of the 
development. 

Currently, a much more primitive development explanation Is maintained by the system 
(see Appendix A). It consists of a linear sequence of state descriptions. Each 
description Is composed of the state name, a comment entered by the developer, and 
tho action taken In that state (such as applying a transformation or loading the Initial 
spoclflcotlon). Structure Is added to the linear sequence only when the action taken 
within the state fails. Development proceeds within the suspended state until the falling 
action succeeds. 

For the development explanation shown In Appendix A, the explication phase 
corresponds to states 1 through 7, the reorganization phase corresponds to states 8 
and 9, and the representation phase corresponds to state 10. 

THE DEVELOPMENT PROCESS 

The development of the Implementation from the formal specification Is described 
Informally here. The actual form of the program at each step Is given In Appendix B, 
which is organized as pairs of program displays that highlight (In bold face) the changes 
from state N into state N+1. These pairs of program displays are produced by the 
system as part of the automatic documentation of a development [B]. 
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In the text that follows, the Informal description of the transition Into a state will be 
preceded by Its state description as given In Appendix A. 

[State-2 (Unfold both constraints) 

(Apply transformation: Unfold-Conslralnt)] 

As the first step In making implicit structures explicit, both constraints contained In 
the original formal specifications are "unfolded." That is, rather than relying on the 
Interpreter of the language to check the constraints after each (relevant) operation and 
to backtrack In case the constraint Is violated, an analysis Is performed to determine 
whoro explicit checks should be Inserted In the program (after assertions that could 
affect the truthfulness of the constraint predicate), and the appropriate checking and 
backtracking code Is added there. This analysis is performed by the unfold-constralnt 
transformation. As part of Its analysis, a simplification of the constraint predicate Is 
performed (because the assertion the check follows will be true and need not be 
rochecked). If this predicate Is satisfied, then the constraint has been violated and the 
call to constraint-violation Is executed, which Invokes the backtracking mechanism to 
reevaluate the most recent nondetermlnlstlc statement (the choice of a board position on 
which to place the Queen). 

Both constraints are unfolded by this transformation, and since each contains two 
Instances of the fact being asserted, each generates two checks which are inserted In 
the program. The constraints, having been unfolded, are removed from the program. 

[Slate-} (Simplify: remove redundant unfolded constraint checks) 

(Manual effort)] 

Because of the symmetry that existed In the constraint patterns, one of the two 
checks generated by the previous transformation for each constraint Is redundant. The 
current system does not Include an automatic simplifier, so either transformations for this 
particular type of simplification must be applied or else the redundant code must be 
manually removed. The latter option was chosen to illustrate this facility within the 
system. 

It Is assumed that situations will Inevitably arise for which the appropriate 
transformation does not already exist within the catalog. Therefore, the developer may 
either define a new transformation (thus extending the catalog) or modify the program 
directly through an Interactive editor (i.e., manually modify the program). It must be 
recognized that both options result In an unvalidated modification of the program (merely 
defining a transformation does not ensure Its validity). In both cases the unvalidated 
stop becomes part of the documentation of the development, which can later be 
reviewed by the others and judged acceptable or not. 

The redundancy of the first pair Is based on simple renaming of free variables, while 
the second also depends upon determining that Queen-Capture Is a symmetric relation. 
The second element of each pair of checks was manually edited out of the program. 
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[State-4 (Make backtracking explicit so that it can be minimixed) 

(Apply transformation: Unfoid-Consequential-Backtracking)] 

The second step In making Implicit structure explicit is now attempted by applying the 
transformation to unfold backtracking (other backtracking transformations can be found 
In references [10, 13]). This transformation converts the Implicit control structure 
nocossery to support resumption of control at a nondeterminism point from an arbitrary 
failure Into a format In which the nondeterminism is embedded In an iterative loop through 
all the possibilities searching for an acceptable one as determined by the loop body 
containing all the possible failure points reexpressed as loop continuation statements. 

The activation pattern for this transformation assumes a recursive format for the 
routine containing the nondeterminism, Unfortunately, when the transformation Is applied 
to the program In State-3, this activation pattern fails to match. This causes the system 
to ask the developer whether he would like to modify ("jitter") the program so that the 
activation pattern will match or abort the application of the current transformation. The 
developer responded that Jittering was desired. The system then enters a subgoallng 
mode In which further development proceeds under the direction of the developer until 
tho suspended activation pattern successfully matches the modified program. At that 
point the development pops out of the subgoal mode and continues application of the 
suspended transformation. 

[State-4-l (Convert iteration to recursion) 

(Jitter transformation: Make-set-iteration-recursive)] 

In the subgoal development the developer applies a transformation (recorded as a 
Jit tor transformation because the developer Is attempting to get the program to conform 
to the requirements of a suspended transformation) that converts the Iteration to a 
recursion. 

It Is instructive to digress for a moment and consider In detail the application of this 
transformation, which Is shown In Figure 2. The transformation contains a comment, an 
activation pattern, a list of modifications and declaration of variables used within the 
transformation. In addition, it could contain properties that the program and/or data had 
to satisfy In order for the transformation to be applicable or properties known to be true 
aftor the transformation was applied. 

The pattern contains variables and literals (all names not declared to be variables). 
Tho variables will be matched against a single expression in the program to which the 
transformation Is applied or against a sequence of expressions (if the variable begins 
with an exclamation mark). When this pattern is applied to the program In State-3, a 
unique match is found in which SET1 Is bound to QUEEN-SET, P2 Is bound to 
(BOARD-POSITION), the segment variable !S 1 Is bound to everything following the DO In 
the FOR statement (the DETERMINE and inner LOCAL statements), etc. If more than a 
single match were found, the developer would have been asked which match to use. If 
no match were found, the developer would have been asked whether the program should 
be jittered or the transformation aborted. 
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MAKE-SET-ITERATION-RECURSIVE 


COMMENT: CONVERT SIMPLE SET ITERATION THROUGH THE (ONLY) 

PARAMETER INTO A RECURSION 

PATTERN: [LAMBDA {SET 1) 

(LOCAL P2 (FOR Of IN-SET SET1 00 IS1) 

!S2 ] 

MODIFICATIONS: [{BIND R1 FROM FNAME) 

(BIND P3 FROM (CONS 01 P2)) 
{REPLACE-PATTERN 
((LAMBDA (SETf) 

(LOCAL P3 (TERMINATION-TEST: 

(IF (EMPTY SETT) 

THEN 

IS2 

(RETURN))) 

(REMOVE Of FROM SET 1) 

•SI 

(RECURSIVE-CALL: {R1 SET1 ] 

PATTERN-VARIABLES: {SET1 !S1 Of P2 !S2 P3 R1 ) 


Figure 2 


Following the pattern match, the applicability properties to be satisfied are checked 
(there are none In this transformation). These properties fall Into two 
categorles--propertles that must be satisfied before the transformation can be applied 
and properties that eventually must be satisfied to validate the applicability of this 
transformation but need not be considered Immediately. Such properties are quite 
Important because they build up "requirements" on the program and/or data that must 
eventually be satisfied, but that because they can be delayed, can be used as guidance 
for the subsequent development. If any Immediate properties were not satisfied, then 
the system would attempt to prove them (currently only through special-purpose 
property provers). Falling that, It would enter a subgoallng mode until further 
development established the Immediate property. 

After the applicability properties are satisfied (or delayed), the modifications are 
performed. These modifications are a linear sequence of actions. The prototypical 
action Is to replace the portion of the program matched by the applicability pattern with 
some new pattern composed of literals and variables. The variables used In this 
replacement pattern can be either bound by the applicability pattern (such as 8ET1) or 
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ones calculated from those variables (such as R1 and P3) through the BIND action. This 
soquence of BIND actions calculating new values that become part of the replacement 
pattorn Is quite typical of the transformations we have studied (and separates them from 
simpler so called "syntactic" transformations Involving only pattern replacement). 

In addition to these actions, other transformations can be applied (providing a means 
to package transformations), arbitrary functions invoked, or a simple plan established 
through goals to be achieved. 

In the current transformation, the BIND action Is used to calculate values for the 
recursive call of the program being transformed (In variable R1) and for the addition of 
the program Iteration variable (QUEEN) to the declaration of variables In the LOCAL 
statement (In the transformation variable P3). These values are then used, along with 
several found directly by the applicability pattern, to form the replacement pattern. 

The resulting program has annotations in the form of labels (names ending with a 
colon), which describe the teleological function of that portion of the program [16]. 
These annotations may well help later transformations access and analyze appropriate 
parts of the program. But as these annotations are currently part of the program text, 
they must be dealt with by succeeding transformations whether they are Interested In 
those annotations or not. This has proved most bothersome. One solution used In the 
MENTOR system [11] is to place these annotations Into orthogonal dimensions accessible 
only by special commands so that the annotations are Invisible for those uninterested. 
Wo expect to employ this solution for all annotations including the maintenance of 
properties. 

After applying the jittering transformation of State 4-1, the modified program 
successfully matches the applicability pattern of the suspended unfold- 
consequentlal-backtracklng transformation, and so processing of this transformation Is 
resumed. The transformation (shown In Figure 3) Is similar In structure to the previous 
transformation as Its modifications consist of a series of BIND actions followed by a 
REPLACE-PATTERN action. Unlike the previous transformation, this one contains some 
NECESSARY-PROPERTIES that must be satisfied before the transformation can be 
applied. The properties are arbitrary predicates applied to the various objects of the 
system being Implemented (such as Its programs, code segments, and data structures). 
In this transformation there are four instances of the same property applied to single 
(but different) arguments consisting of a code segment Identified by the match of the 
transformation-applicability pattern. Aside from a small number of bullt-ln properties 
dlroctly relating to the semantics of the specification language (and produced and 
maintained by an analysis package soon to be Incorporated within the system), all other 
properties must either be defined In terms of other properties (theorem-proving 
techniques will be used to determine whether or not the property Is satisfied) or 
self-defined through direct generation as the result (the KNOWN property) of some 
transformatlon(s) and/or deduction through special-purpose property provers. Typically 
for self-defined properties, no explicit formal definition exists. 






AN EXAMPLE 


0 


UNFOLD-CONSEQUENTIAL-BACKTRACKING 


COMMENT: MAKE BACKTRACKING EXPLICIT 

PATTERN: (LOCAL VI (TERM I NAT I ON-TEST: (IF P2 THEN IS8 (RETURN))) 

!S1 

(DETERMINE Ol FROM PI) 

!S2 

(RECURSIVE-CALL: S3) 

!S4) 

NECESSARY PROPERTIES: ((CONSEQUENT IAL-NON-OE TERM INISM-FREE !S1) 

(CONSEQUENTIAL-NON-DETERMINISM-FREE !S2) 

(CONSEQUENT IAL-NON-DETERMINISM-FREE !S4) 
(CONSEQUENTIAL-NON-DETERMINISM-FREE 'S5)) 

MODIFICATIONS: [ {BIND !S2 * FROM 

(UNFOLO-CONSEQUENTIAL-BACKTRACKING-BUILDER IS2 )) 

I BIND IS2UNDO FROM (UNDO-OF (ACTIVE-PREDECESSORS-OF 

NIL IS2 ] 

[BIND IS1UNDO FROM (UNDO-DF (ACTIVE-PREDECESSORS-OF 

NIL IS11 

(BIND !S5‘ FROM (UNFOLO-CONSEQUENT IAL-BACK TRACK I NG-BUI LDER 
IS5 T)) 

( REPLACE-PATTERN 

((LOCAL VI (TERMINATION-TEST: (IF P2 THEN ?S5* 

(EXIT SUCCESSFUL))) 

I SI 

(FOR ALL PI THERE IS !S2* 

(IF (SUCCESSFUL (RECURSIVE-CALL: S3)) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: IS2UNDO) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

!S4 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: I SI UNDO) 

(EXIT UNSUCCESSFUL] 


PATTERN-VARIABLES: (/Sf IS2 IS4 IS2* (S2UNDO I SI UNDO VI P2 Pi 

S3 01 !SS M IS5) 
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The property (CONSEQUENTIAL-NON-DETERMINISM-FREE) used In this transformation Is 
defined only through its special-purpose property prover. Informally, the property means 
that the code segment to which it is applied does not contain any "meaningful" 
nondeterminism. This Is Important because this transformation rearranges the program so 
that any "backtracking point" Is part of the still active loop; backtracking can then be 
accomplished by merely continuing that loop (after undoing any actions taken within the 
loop). It assumes that only one such backtracking point exists, and uses the property to 
validate this assumption. The concern Is that only a single backtracking point exists and 
the existence of "Incidental" nondeterminism is of no consequence. In the program of 
State 4-1 there are two nondetermlnlstlc statements, the selection of a queen and the 
determination of where to place it on the chessboard. The first of these Is Incidental In 
that It doesn't matter which queen Is selected. But the second is consequential 
because the course of subsequent processing is highly dependent upon the choice 
mode. Thus, In backtracking, only the nondeterminism of the selection of a board position 
should be considered as the other, Incidental choice of a queen doesn't affect the 
subsequent processing. 

After the applicability pattern of the transformation has been matched, the system 
attompts to verify that the necessary properties are satisfied. The first property is 
CONSEQUENTIAL-NON-DETERMINISM-FREE applied to the segment !S1 which is bound to 
tho statement (REMOVE QUEEN FROM QUEEN-SET). The method of verifying this property 
Is to Invoke Its special-purpose property prover, which falls because It is unable to tell 
that this nondeterminism Is incidental. Because a necessary property couldn't be 
verified, the system enters a subgoal mode (through a self-generated ACHIEVE command 
resulting In State 4-2) under which further development will continue until the necessary 
property Is achieved. An appropriate message to this effect is given to the developer. 

[State 4-2-1 (Mark "REMOVE" as incidental nondeterminism) 

(Apply transformations: Mark-incidental-non-determinism)] 

The developer responds to this problem by applying a transformation that marks the 
REMOVE statement as Incidental (by converting It to REMOVE*). This transformation has 
as a requlrod property that the choice of the object being removed (Queen) Is Incidental. 
Since this Is a required rather than an Immediate property, It need not be verified 
immediately, and so It Is added as an UNPROVED-PROPERTY of the current state. Such 
properties must be either proved (by one of the methods described previously) or 
claimed (assumed by the user to be true) before the development Is completed. Any 
claims (developer assumptions) become part of the documentation of the development. 

After each step of the development In the subgoal mode, the system attempts to 
dotermlne whether the property to be achieved can be verified. Here, the appropriate 
mnthod Is to relnvoke the special-purpose property prover on code segment !S1. 
However, the transformation just applied modified this code segment and the new value 

1 must be used. This Is accomplished by rematching the suspended applicability pattern to 

obtain the appropriate code segment. In fact, since the subgoal development logically 
procedes the suspended transformation, the suspended transformation Is reprocessed 
after each subgoal development step. 

j 

i 



With !S1 rebound to (REMOVE* QUEEN FROM QUEEN-SET), the special-purpose property 
prover Is successful In verifying the CONSEQUENTIAL-NON-DETERMINISM-FREE property. 

Verification of the first Instance of the CONSEQUENTIAL-NON-DETERMINISM-FREE 
property completes the processing of the subgoal ACHIEVE state, and processing of 
State 4 resumes with attempts to verify the other Instances of this property, all of which 
succeed. 

Processing then continues with the modification steps. The second and third BIND 
actions find the active statements within some code segment and then build a sequence 
that undoes their effects (so that when control Is returned to the "backtracking point" 
[now In the form of an interactive loop] the program state has been restored to Its state 
when control was last there). The first and last BIND actions locate any 
CONSTRAINT-VIOLATION statements occurring In the program and replace them by the 
undo of the active statements preceding the CONSTRAINT-VIOLATION statement (and 
following the nondetermlnlstic choice) followed by a loop continuation statement (to the 
loop being Introduced by this transformation). After all the BIND actions have been 
processed, the replacement pattern Is constructed and substituted for the portion of the 
program matched by the transformation's applicability pattern. 

[State 5 (Assimilate constraint into generator) 

(Apply transformation: Assimilate-test-in-thesis-loop)] 

The final stage In explicating the underlying structure of the algorithm Is to 
Incorporate Into Its selection the constraints that a board position must satisfy. Here, 
these constraints are tested after a queen is placed on the board at the selected 
position (because the constraints were originally stated in terms of pieces on the board), 
and If the position is unacceptable, then the queen Is removed from the board and 
another selection made. In general, more efficient processing results when a selection Is 
based on all such restrictions that It must satisfy. Toward this end, the developer 
attempts to apply a transformation to assimilate one of these restrictions Into the 
generator of board positions. (This same transformation will be applied again to assimilate 
the other restrictions.) Unfortunately the applicability pattern of this transformation 
requires that the restriction being assimilated be the first statement of the body of the 
1 »r-loop In which the generator occurs, and this fails to match the program. As before, 
the system asks the developer whether jittering Is desired, and when affirmed, Initiates 
a subgoai development (which will take several steps before the suspended applicability 
pattern can be matched). 

[State 5-1 (Merge the locals) 

(Jitter transformation: Merge-locals)] 

As the first step In the Jittering process, the developer attempts to merge the LOCAL 
Inside the for-loop with the outer LOCAL. Again the applicability pattern falls because 
the two LOCALS being merged must be separated by only a single level of nesting (here 
the Inner LOCAL Is Inside the for-loop, which Is inside the LOCAL), and so (after 
confirmation by the developer) another level of jittering Is Initiated. 




12 
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(Slate 5-1-1 (Extract LOCAL from for-loop) 

(jitter transformation: Extract-local-from-for-loop)] 

The developer applies a transformation that extracts the LOCAL from within the 
for-loop. This transformation enables the suspended applicability pattern of the 
Merge-locals transformation to succeed and so ends this level of jittering. 

The suspended applicability pattern matched the Jittered program and the 
transformation's modification steps are performed. First a BIND statement Is used to 
calculate the combined set of variable declarations, and then the replacement pattern Is 
formed which contains the combined declarations and In which the statements of the 
Inner LOCAL are embedded within the outer one. (As noted previously, the current system 
does not yet employ orthogonal annotation dimensions [11]. Here the LOCAL statements 
ore used solely to scope variables. If this variable scoping were handled as an 
annotation It would not Impede the development as It does here.) 

[State 5-3 (Move constraint test ahead of assertion) 

(Jitter transformation: Move-constraint-uphil))) 

The restriction has now been moved to the top level of the for-loop body, but It 
follows the assertion (rather than preceding It, as required by the suspended assimilation 
applicability pattern). The developer applies the Move-constralnt-uphlll to interchange 
tho order of the restriction and the assertion preceding. 

To interchange these two statements, their mutual Interactions must be revised to 
soloct the new ordering. This leaves the assertion unchanged since It has no 
dependence on the restriction. However, both the predicate and body of the restriction 
must (In general) be updated tc reflect knowledge of the existence of the assertion that 
now follows them. Thus, If the predicate depended, In part, on the existence of the 
assertion, It must be modified to Incorporate this dependence without actually accessing 
tho data (because It will not yet exist). In the current case, the predicate Is 
Independent of the assertion, and so is not changed. On the other hand, the THEN clause 
donles the assertion before forcing another iteration of the selection loop, and thus, Is 
highly dependent upon the assertion. The semantics of the program is maintained If the 
denial Is removed (whenever another Iteration is forced, the assertion will not exist). 
Those modifications to the program are calculated by special-purpose analysis routines 
(colled as part of the transformation's BIND actions), Incorporated Into the replacement 
pattern, and substituted Into the program. 

[State 5-5 (Simplify: suppress null else clause) 

(jitter transformation: Else-suppression)] 

Although the restriction Is now In the right location (as the first statement In the 
for-toop body), the suspended applicability pattern still doesn't match because It 
requires the restriction to be an IF-THEN statement (with no ELSE clause), and this 
restriction has an ELSE clause whose body Is NIL. 
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The fact that this match falls because of this trivial problem points up two difficulties 
with the current system. First, no automatic simplification exists. Such simplification 
would (If It existed) certainly have removed this null ELSE clause when it was created 
(by the unfold-constralnt transformation In State 2). Second, given that a simple 
mismatch exists between the applicability pattern and program, rather than have jittering 
be a manual process (as it currently Is), the system should automatically jitter the 
program so that the desired transformation can be applied (we are working to resolve 
both these deficiencies). Here, the developer had to apply a simplification 
transformation to remove the null ELSE clause. This modification enabled the suspended 
applicability pattern to succeed, and so, processing of the jittering subgoal development 
Is completed. 

The suspended applicability pattern succeeds, and the replacement pattern Is formed 
by composing a new loop predicate consisting of the conjunctions of the old loop 
predicate and the negation of the restriction predicate. The rest of the restriction (the 
IF-THEN structure and the body of the THEN clause) is deleted and Its semantics are now 
part of the loop Itself. 

(State 6 (Assimilate remaining constraint into loop generator) 

(Apply transformation: Assiinilate-test-in-thesis-loop)] 

The sequence of State 5 (without having to bother with the LOCALs) is repeated 
(Interchanging the order of the restriction and the assertion, and suppressing the null 
ELSE clause) to incorporate the remaining restriction Into the loop generator. 

(State 7 (Simplify: remove embedded AND in loop generation) 

(Apply transformation: Simplify-AND)] 

The embedded conjunction within the loop predicate Is merged with the outer 
conjunction. Automatic simplification would, when added to the system, remove the need 
for this step. 

(State 8 (Maintain acceptable board positions incrementally) 

(Apply transformation: Calculate-predicatc-incrementally)] 

The simplification performed In the previous state completes the explication phase of 
the development whose purpose was to reveal the underlying structure of the algorithm 
Implicit In the original specification. This structure is quite clear In State 7. A simple 
recursive program exists In which on each recursive level, a queen Is removed from the 
set of queens and placed on a position on the chess board not already occupied and not 
capturable by any queen already on the chess board. The recursion Is then carried out 
at the next level and If It (and all Its recursive calls) Is successful, the algorithm 
terminates. If not, the queen Is removed from the board and another position selected. 

The computationally expensive part of this algorithm Is finding an acceptable board 
position. The developer recognizes that this same calculation (In a slightly altered 
environment with an extra queen placed on the board) Is carried out at each level, and 
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decides that rather than repeat these similar calculations, the set of acceptable board 
positions should be maintained Incrementally. That Is, as actions affecting the 
membership of the set occur within the program, appropriate maintenance actions are 
Inserted to update the set membership accordingly. The actions that can affect set 
membership are the assertion and/or denial of facts which Interact with the set 
definition predicate. Such statements are either preceded (assertions) or followed 
(donlols) by the necessary maintenance actions. Furthermore, the Iteration through the 
eloments of the set Is changed from a generative format (FOR ALL <predlcate>...) to 
slmplo membership In a preexisting set (FOR <X> IN-SET <set>...). 

These modifications are all made automatically by the Calculate- 
predlcate-lncrementally transformation. The calculation of the precise predicate to use 
to update the set membership Is quite complex (see [3] for the details and [15] for the 
foundations of these Ideas), but the general idea Is straightforward: given the newfound 
truth (or falseness) of a fact, what else must necessarily be true to make the set 
definition pattern change Its value (that Is, become true or become false, or equivalently, 
to have the support of the corresponding set element(s) change) and to ensure that no 
othor support exists for these elements? That Is, what must be true to detect the 
emotion of the first support of an element or the deletion of Its last support? Only then 
should it be added to, or deleted from, the set. 

For the set of board positions, this maintenance predicate, following the placement of 
a queen on the board or Its removal, is determined to be the set of board positions that 
are on the chess board, are not occupied by any other piece, ARE capturable by the 
queen being placed on the board or removed from It, and are not capturable by any other 
queen already on the board. 

Actually, since the PIECE-oN-BOARD pattern occurs twice In the set definition 
predicate, two maintenance action loops are generated. The first of these Is concerned 
only with the position occupied by the queen (or about to be occupied by It), while the 
second maintenance loop Is the one described above. 

[Stair 9 (Simplify: remove redundant loop from maintenance actions) 

(Manual effort)] 

The single position handled by the first maintenance loop Is also handled by the 
second, more general, loop. It Is therefore redundant, and the developer used the editor 
to manually remove the first maintenance loop (both the occurrence preceding the 
assertion and the occurrence following the denial). 

[State 10 (Pick a representation for board positions) 

(Manual effort)] 

State 9 completes the reorganization phase of the development accomplished by 
deciding to employ Incremental set maintenance. The final phase deals with determining 
representations appropriate for the processing. At this stage, the expensive part of the 
processing is determining within the maintenance actions whether particular positions are 

i 

I 

I 






AN EXAMPLE 


IS 


capturable by any queen. Is there a representation In which this operation can be more 
easily performed? 

The time has come for the developer to Introduce a little creative magic (It is at Just 
those points that a purely automatic approach seems most suspect). By switching the 
vlowpolnt from positions to lines (l.e., rows, columns, and diagonals) the problem Is 
greatly simplified. That Is, rather than Incrementally maintaining the set of remaining 
board positions explicitly, the set of remaining lines is Incrementally maintained and the 
remaining board positions are generated from them (as the Intersection of four of the 
remaining lines: a row, a column, and two diagonals). In this representation, maintaining 
tho sot of remaining lines when a queen is placed on the board (or removed from It) 
morely Involves deleting (or adding) the corresponding lines (the row, the column, and 
two diagonals) without any search. Furthermore, the iteration through the remaining 
board positions becomes a quadruply nested loop through the remaining rows, columns, 
and left and right diagonals finding four lines that Intersect at a single position. Since a 
position is uniquely determined by a row and column, the Inner two loops can be replaced 
by checks of whether the corresponding diagonals remain. 

These modifications produce the program in State 10. It was produced by manual 
editing, but we are investigating how this step can be formulated as a representation 
alteration transformation (called type transformations [19]). 

REMAINING OPTIMIZATIONS 

A few steps remain to complete the optimization and convert the program Into 
conventional form. They include removing the outer loop through the rows (since each 
row must have a queen and failure to place a queen in a row cannot be resolved by 
reconsidering that row again later), eliminating the use of the set of queens used only to 
determine termination (by using any one of the other sets which become empty at the 
same time), explicitly collecting the set of queen placements as the result of the 
computation rather than having It be implicit In the set of assertions In the data base, 
and using lists (or arrays) Instead of sets. 

We have not yet worked on these optimizations pending resolution of the 
representation selection Issue. 

CONCLUSIONS 

Using a transformation system to develop the Implementation of a small, but nontrivial 
example, such as the Eight Queens problem presented here, Is both instructive and 
disconcerting. 

Developing an Implementation through the application of formalized transformations 
forces a more careful consideration of the strategy to be employed, and the tradeoffs 
Involved. This highly beneficial result represents a shift In focus away from maintaining 
consistency, which almost completely consumes today's programmers, toward a concern 
with tradeoffs between alternative Implementations. With the system assuming the 









responsibility for maintaining consistency, the developer should be free to concentrate 
on these higher level Issues. Such consideration of the Implementation tradeoffs 
heightens the need for adequate specifications that merely define the required behavior 
without determining how It Is to be achieved. 

However, It Is quite evident from the development presented here that the developer 
has not been freed to consider Implementation tradeoffs. Instead of a concern for 
maintaining consistency, the equally consuming task of directing the low-level 
development has been Imposed. While the correctness of the program Is no longer an 
Issue, keeping track of both where one Is In a development and how to accomplish each 
stop In all Its fine detail diverts attention from the tradeoff question. 

It Is quite clear that If transformation systems are to become useful, this difficulty 
must be removed. Automatic simplification and jittering, as discussed In this report, will 
help considerably (see also [12]). But equally important is the ability to state, 
represent, refine, and display Implemention plans. The current lack of an adequate 
framework in which the development proceeds is a major source of conceptual overload. 

Major Improvements are also needed In the documentation of developments to make 
them understandable. The ability to highlight changes between successive states, as 
Illustrated In Appendix B, Is but a first step. The structure of the development plan must, 
become an Integral part of Its documentation and understanding. 

Finally, If implementation tradeoffs are to gain prominence, and If systems developed 
via transformations are to be maintained, the ability must be created to replay a slightly 
altered development (l.e., the altered development becomes the Implementation plan to 
be carried out largely or completely automatically). 

All of the above benefits and problems are present only on the assumption that people 
are Involved In the development process. If this process were tQtally automated, then 
none of these Issues would arise. However, given the growing concern with starting a 
development from a very high-level (and largely noncomputatlonal) specification, and the 
paucity of information known about strategic optimization that Is central to Implementing 
such specifications, It seems unlikely that fully automatic systems could deal effectively 
with such specification languages. Rather, one would expect to see a gradual raising of 
the level of the languages that can be automatically optimized. Thus, the role of 
Interactive transformation systems will be to provide a validated mapping between the 
high-level specifications and the "programming language" from which automatic 
optimization can proceed. 
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n 


(STATE-1 (ENTER SPECIFICATION FOR EIGHT QUEENS PROBLEM) 

(LOAO FILE EIGHT-QUEENS.SPEC)) 

(STATE-2 (UNFOLD BOTH CONSTRAINTS) 

(APPLY TRANSFORMATION . UNFOLD-CONSTRAINT)) 

(STATE-3 (SIMPLIFY: REMOVE REDUNDANT UNFOLDED CONSTRAINT CHECKS) 
(MANUAL EFFORT)) 

(STATE-4 (MAKE BACKTRACKING EXPLICIT SO THAT IT CAN BE MINIMIZED) 

(APPLY IHANSFOHMA I ION . UNFOLU-CONSEQUENT1AL-BACKTRACKING) ) 

(STATE-4-1 (CONVERT ITERATION TO RECURSION) 

(JITTER TRANSFOMATION . MAKE-SET-ITERATIDN-RECURSIVE)) 

(STATE-4-2 (ACHIEVE A NECESSARY PROPERTY OF A TRANSFORMATION) 
(ACHIEVE THE FOLLOWING PROPERTY: 

CONSEQUENTIAL-NON-DETERMINISM-FREE 
REMOVE QUEEN FROM QUEEN-SET))) 

(STATE-4-2-1 (MARK "REMOVE" AS INCIDENTAL NON-DETERMINISM) 
(APPLY TRANSFORMATION . 

MARK-1NCIDENTAL-NON-DE TERMINISM)) 

(STATE-4-2-2 

NIL 

((CONSEQUENTIAL-NON-OETERMINI5M-FREE (REMOVE* QUEEN FROM 

QUEEN-SET)) 

PROVED BY NO-CONSEQUENTIAL-NON-DETERMINISM)) 

(STATE-4-3 

(ACHIEVE A NECESSARY PROPERTY OF A TRANSFORMATION) 

((CONSEQUENT IAL-NON-OETERMINISM-FREE 
(LOCAL . . . ) 

PROVED BY NO-CONSEQUENTIAL-NON-DETERMINISM)) 

(STATE-4-4 (ACHIEVE A NECESSARY PROPERTY OF A TRANSFORMATION) 

((CONSEQUENT IAL-NON-DETERMINISM-FREE) 

PROVED BY NO-CONSEQUENTIAL-NON-DETERMINISM)) 








(STATE-5 (ASSIMILATE CONSTRAINT INTO GENERATOR) 

(APPLY TRANSFORMATION . ASSIMILATION-TEST-IN-THEREIS-LOOP)) 

(STATE-5-1 (MERGE THE LOCALS) 

(JITTER TRANSFORMATION . MERGE-LOCALS)) 

(STATE-5-1-1 (EXTRACT LOCAL FROM FOR LOOP) 

(JITTER TRANSFORMATION . 

EXTRACT-LOCAL-FROM-FOR-LOOP)) 

(STATE-5-3 (MOVE CONSTRAINT TEST AHEAD OF ASSERTION) 

(JITTER TRANSFORMATION . MOVE-CONSTRAINT-UPHILL)) 

(STATE-5-5 (SIMPLIFY: SUPPRESS NULL ELSE CLAUSE) 

(JillEH IHANSFOHMAIION . ELSE-SUPPRESS10N)) 

(5TATE-G (ASSIMILATE REMAINING CONSTRAINT INTO LOOP GENERATOR) 

(APPLY TRANSFORMATION . ASS1MI LATE-TEST-1N-THEREIS-LOOP)) 

(5TATE-G-1 (MOVE REMAINING CONSTRAINT AHEAD OF ASSERTION) 

(JITTER TRANSFORMATION . MOVE-CONSTRAINT-UPHILL)) 

(STATE-6-3 (SIMPLIFY: SUPPRES5 NULL ELSE CLAUSE) 

(JITTER TRANSFORMATION . ELSE-SUPPRESSION)) 

(STATE-7 (SIMPLIFY: REMOVE EMBEDDED APAND IN LOOP GENERATOR) 

(APPLY TRANSFORMATION . SIMPLIFY-APAND)) 

(STATE-8 (MAINTAIN ACCEPTABLE BOARD POSITIONS INCREMENTALLY) 

(APPLY TRANSFORMATION . CALCULATE-PREDICATE-INCREMENTALLY)) 

(STATE-3 (SIMPLIFY: REMOVE REDUNDANT LOOP FROM MAINTENANCE ACTIONS) 
(MANUAL EFFORT)) 

(STATE-10 (PICK <ROUtf COLUMNS AS REPRESENTATION OF BOARD POSITION. 

RECOGNIZE THAT COMPONENTS ARE ORTHOGONAL AND CAN BE 
INDEPENDENTLY SELECTED. FURTHERMORE. RECOGNIZE THAT 
ROU AND COLUMN DETERMINE NE-DIAGONAL AND SE-DIAGONAL. 
FINALLY, RECOGNIZE THAT POSSIBLE BOARD-POSITIONS CAN BE 
GENERATED FROM THE INTERSECTION OF THE REMAINING ROUS, 
COLUMNS. AND DIAGONALS. AND THAT INCREMENTAL UPDATE 
OF POSSIBLE-BOARD-POSITIONS MERELY INVOLVES REMOVING 
THE CHOSEN ROU. COLUMN. AND TUO DIAGONALS BECAUSE 
THE MAPPING IS ONE-TO-ONE IN BOTH DIRECTIONS.) 

(MANUAL EFFORT)) 
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This appendix contains pairs of program displays In which the changes from one state 
Into another are highlighted In boldface type. The deleted and/or modified text Is 
highlighted to show the changes out of a state, while the additions and modifications are 
highlighted to show the changes Into the next state. These pairs of program displays are 
placed on facing pages for ease of comparison. They were produced automatically as 
part of the documentation of the development [9]. 





TRANSFORMATIONAL IMPLEMENTATION: 


CHANGES OUT OF STATE-1 

(LAMBDA (QUEEN-SET) 

(LOCAL (BOARD-POSITION) 

(FOR QUEEN IN-SET QUEEN-SET DO 

(DETERMINE BOARD-POSITION FROM 

(CHESS-BOARD BOARD-POSITION)) 
(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION) 
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CHANGES INTO STATE-2 


(LAMBDA (QUEEN-SET> 

(LOCAL (BOARD-POSITION) 

(FOR QUEEN IN-SET QUEEN-SET DO 
(DETERMINE BOARD-POSITION FROM 

(CHESS-BOARD BOARD-POSITION)) 

iLOCAL ( BOARD-POSITION02 BOARD-POSITION01 QUEEN02 QUEEN01 
PIECE02 PIECE01 > 

. (ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF < PIECE-ON-BOARD PIECE02 BOARD-POSITION > 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PI ECES-CAN'T-OCCUPY-SAME-SQU ARE) 

ELSE NIL > 

(IF (PIECE-ON-BOARD PIECE01 BOARD-POSITION > 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PI ECES-CAN'T-OCCUPY-SAME-SQU ARE) 

ELSE NIL) 

(IF «AND (PIECE-ON-BOARD QUEEN02 BOARD-POSITION02) 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSIT I ON 02) > 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CAN'T-CAPTURE-ANOTHER-QUEEN) 

ELSE NIL) 

(IF (AND (PIECE-ON-BOARD QUEEN 01 BOARD-POSIT I ON 01 > 
(QUEEN-CAPTURE BOARD-POSITION01 
BOARD-POSITION)) 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CAN'T-CAPTURE-ANOTHER-QUEEN) 

ELSE NIL 
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CHANGES OUT OF STATE-2 


ILAMBDA (QUEEN-SET) 

(LOCAL (BOARD-POSITION) 

(FOR QUEEN IN-SET QUEEN-SET DO 
(DETERMINE BOARD-POSITION FROM 

(CHESS-BOARD BOARD-POSITION)) 

(LOCAL (BOARD-POSITION*2 BOARD-POSITION* 1 QUEEN*2 QUEEN* 1 
PIECE*2 PIECE* 1) 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (PIECE-ON-BOARD PIECE*2 BOARD-POSITION) 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PIECES -CAN’T-OCCUPY-SAME-SQUARE) 

ELSE NIL) 

(IF (PIECE-ON-BOARD PIECE01 BOARD-POSITION > 

THEN 

CONSTRAINT-VIOLATION 

TWO-PIECES-CAN'T-OCCUPY-SAME-SQUARE) 

ELSE NIL 

(IF (AND (PIECE-ON-BOARD QUEEN*2 BOARD-PO$IT!ON*2> 

(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITION*2>) 

THEN 

(CONS T RAINT-VIOLATION 

QUEEN-CAN’T-CAPTURE-ANOTHER-QUEEN) 

ELSE NIL) 

(IF (AND (PIECE-ON-BOARD QUEEN 01 BOARD-POSIT I ON 01 > 
( QUEEN-CAPTURE BOARD-POSITION01 
BOARD-POSITION >> 

THEN 

CONSTRAINT-VIOLATION 

QUEEN-CAN'T-CAPTURE-ANOTHER-QUEEN) 

ELSE NIL 








AN EXAMPLE 


23 


CHANGES INTO STATE-3 


(LAMBDA (QUEEN-SET) 

(LOCAL (BOARD-POSITION) 

(FOR QUEEN IN-SET QUEEN-SET DO 
(DETERMINE BOARD-POSITION FROM 

(CHESS-BOARD BOARD-POSITION)) 

(LOCAL (B0ARD-P0SITI0N*2 BOARD-POSITION* 1 QUEEN*2 QUEEN* 1 
PIECE*2 PIECE* 1) 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (PIECE-ON-BOARD PIECE*2 BOARD-POSITION) 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PIECES-CANT-OCCUPY-SAME-SQUARE) 

ELSE NIL) 

(IF (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSlTION*2) 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITION*2>> 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CAN’T-CAPTURE-ANOTHER-QUEEN) 

ELSE NIU 








TRANSFORMATIONAL IMPLEMENTATION. 


CHANGES OUT OF STATES 

(LAMBDA (QUEEN-SET) 

(LOCAL (BOARD-POSITION) 

(FOR QUEEN IN-SET QUEEN-SET DO 

(DETERMINE BOARD-POSITION FROM 

(CHESS-BOARD BOARD-POSITION)) 

(LOCAL (B0ARD-P0SITI0N«2 BOARD-POSITION# 1 QUEEN#2 QUEEN# 1 
PIECE#2 PIECE# 1). 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (PIECE-ON-BOARD PIECE#2 BOARD-POSITION) 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PIECES -CAN'T-OCCUPY-SAME-SQUARE) 

ELSE NIL) 

(IF (AND (PIECE-ON-BOARD QUEEN#2 BOARD-POSITION#2) 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITION#2)> 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CANT-CAPTURE-ANOTHER-QUEEN) 

ELSE N1U 


i 

I 
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CHANGES INTO STATE-4-1 


CLAMBOA (QUEEN-SET) 

(LOCAL ( QUEEN BOARD-POSITION > 

(TERMINATION-TEST: (IF t EMPTY QUEEN-SET) 

THEN 

(RETURN))) 

(REMOVE QUEEN FROM QUEEN-SET) 

(DETERMINE BOARD-POSITION FROM (CHESS-BOARD BOARD-POSITION)) 
(LOCAL (B0ARD-P0SITI0N«2 BOARD-POSITION# 1 QUEEN#2 QUEEN# 1 
PIECE#2 PIECE# 1) 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (PIECE-ON-BOARD PIECE#2 BOARD-POSITION) 

THEN 

(CONSTRAINT -VIOLATION 

TWO-PIECES-CANT-OCCUPY-SAME-SQUARE) 

ELSE NIL) 

(IF (AND (PIECE-ON-BOARD QUEEN#2 BOARD-POSITION#2> 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION#2)> 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CANT-CAPTURE-ANOTHER-QUEEN) 

ELSE NIL)) 

(RECURSIVE-CALL: (QUEENS QUEEN-SET j 


j 


t 





transformational implementation. 


CHANGES OUT OF STATE-4-1 


(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(RETURN))) 

iREMOVE QUEEN FROM QUEEN-SET) 

(DETERMINE BOARD-POSITION FROM (CHESS-BOARD BOARD-POSITION)) 
(LOCAL (BOARD-POSITION*2 BOARD-POSITION* 1 QUEEN*2 QUEEN* 1 
PIECE*2 PIECE* 1) 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (PIECE-ON-BOARD PIECE-2 BOARD-POSITION) 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PIECES-CAN’T -OCCUPY-SAME-SQUARE) 

ELSE NIL) 

(IF (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSITION*2) 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION*2>> 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CANT-CAPTURE-ANOTHER-QUEEN) 

ELSE NIL)) 

(RECURSIVE-CALL: (QUEENS QUEEN-SET) 





AN EXAMPLE 
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CHANGES INTO STATE-4-2-1 


[LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(RETURN))) 

(REMOVE * QUEEN FROM QUEEN-SET) 

(DETERMINE BOARD-POSITION FROM (CHESS-BOARD BOARD-POSITION)) 
(LOCAL (BOARD-POSITIONS BOARD-POSITION* 1 QUEEN*2 QUEEN* 1 
PIECE«2 PIECE* 1) 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (PIECE-ON-BOARD PIECE*2 BOARD-POSITION) 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PIECES -CANT-OCCUPY-SAME-SQUARE) 

ELSE NIL) 

(IF (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSITION*2) 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION*2)> 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CANT-CAPTURE-ANOTHER-QUEEN) 

ELSE NIL)) 

(RECURSIVE-CALL: (QUEENS QUEEN-SET) 





TRANSFORMATIONAL IMPLEMENTATION! 


CHANGES OUT OF STATE-4-2-1 


(LAMBDA (QUEEN-SET> 

(LOCAL (QUEEN BOARD-POSITION) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

( RETURN j 

(REMOVE* QUEEN FROM QUEEN-SET) 

(DETERMINE BOARD-POSITION FROM (CHESS-BOARD BOARD-POSITION)) 
(LOCAL (BOARD-POSITION«2 BOARD-POSITION* 1 QUEEN*2 QUEEN* 1 
PIECE*2 PIECE* 1) 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (PIECE-ON-BOARD PIECE*2 BOARD-POSITION) 

THEN 

(CONSTRAINT-VIOLATION 

TWO-PIECES-CAN'T-OCCUPY-SAM E-SQUARE) 

ELSE 

NIL) 

(IF (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSITION*2) 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION«2)) 

THEN 

(CONSTRAINT-VIOLATION 

QUEEN-CAN‘T-CAPTURE-ANOTHER-QUEEN) 

ELSE 

NIL)) 

(RECURSIVE-CALL: (QUEENS QUEEN-SET) 



AN EXAMPLE 
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CHANGES INTO STATE-4 


(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EX/7 SUCCESSFUL 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL (CHESS-BOARD BOARD-POSITION) 

TNEREIS 

(LOCAL (BOARD-POSITIONS BOARD-POSITION* 1 QUEENS QUEEN* 1 
PIECES PIECE* 1) 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION) > 

(IF (PIECE-ON-BOARD PIECES BOARD-POSITION) 

THEN 

(UNDO-ACTIONS: (DENY < PIECE-ON-BOARD QUEEN 

BOARD-POSITION >>> 

(LOOP-RETURN FORCE-ANOTHER-CHOICE > 

ELSE 

NIL) 

(IF (AND (PIECE-ON-BOARD QUEENS BOARD-POSITIONS) 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITIONS)) 

THEN 

(UNDO-ACTIONS: (DENY < PIECE-ON-BOARD QUEEN 

BOARD-POSITION .>> 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE 

NIL)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET] 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED > 

ELSE 

( UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) > 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL 






TRANSFORMATIONAL IMPLEMENTATIONS 


CHANGES OUT OF STATE-4 


(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL (CHESS-BOARD BOARD-POSITION) 

THEREIS 

(LOCAL (BOARD-POSITION*2 BOARD-POSITION* 1 QUEEN*2 QUEEN* 1 
PIECE*2 PIECE* 1) 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (PIECE-ON-BOARD PIECE*2 BOARD-POSITION) 

THEN 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(IF (ANO (PIECE-ON-BOARD QUEEN*2 BOARD-POSITION*2) 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITION*2)) 

THEN 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE ML)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)> 

(EXIT UNSUCCESSFUL) 









AN EXAMPLE 
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CHANGES INTO STATE-8-1-1 


tLAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(LOCAL (BOARD-POSITION«2 BOARD-POSITION* 1 QUEEN«2 QUEEN* 1 
PIECE*2 PIECE* 1) 

(FOR ALL (CHESS-BOARD BOARD-POSITION) 

THEREIS 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (PIECE-ON-BOARD PIECE*2 BOARD-POSITION) 

THEN 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(IF (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSITION*2) 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITION»2)> 

THEN 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET)) 
) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADO QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL] 
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TRANSFORMATIONAL IMPLEMENTATION! 


CHANGES OUT OF STATE-5-1-1 


(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION > 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(LOCAL (BOARD-POSITION HI 2 BOARD-POSITION#! QUEEN02 QUEEN# 1 
PIECE#2 PIECE# 1, 

(FOR ALL (CHESS-BOARD BOARD-POSITION) 

THEREIS 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (PIECE-ON-BOARD PIECE«2 BOARD-POSITION) 

THEN 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(IF (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSITION«2> 

(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITION*2>> 

THEN 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET)) 

) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADO QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL] 





AN EXAMPLE 
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CHANGES INTO STATE-5-1 


(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION BOARD-POSITION#2 BOARD-POSIT I ON*1 QUE 
QUEEN01 PIECE#2 PIECE#1 > 

(TERMINATION-TEST: <IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL (CHESS-BOARD BOARD-POSITION) 

THEREIS 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (PIECE-ON-BOARD PIECE*2 BOARD-POSITION) 

THEN 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION) >) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(IF (AND (PIECE-ON-BOARD QUEEN«2 BOARD-POSITION*2> 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION«2)> 

THEN 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET>>) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) > 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNOO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL) 
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TRANSFORMATIONAL IMPLEMENTATION) 


CHANGES OUT OF STATE-S-1 


(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION BOARD-POSITIONS BOARD-POSITION* 1 QUEENS 
QUEEN* 1 PIECE *2 PIECE* 1) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL (CHESS-BOARD BOARD-POSITION) 

THEREIS 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (PIECE-ON-BOARD PIECES BOARD-POSITION) 

THEN 

iUNDO-ACTIONS: tDENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION >>> 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE 

NIL) 

(IF (AND (PIECE-ON-BOARD QUEENS BOARD-POSITIONS) 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITIONS) > 

THEN 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNOO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL) 




AN EXAMPLE 
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CHANGES INTO STATE-5-3 


(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION B0ARD-P0SITI0N*2 BOARD-POSITION* 1 QUEEN*2 
QUEEN* 1 PIECE*2 PIECE* 1) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL (CHESS-BOARD BOARD-POSITION) 

THEREIS 

(IF (PIECE-ON-BOARD PIECE*2 BOARD-POSITION) 

THEN 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITIONn 
(IF (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSITlON*2) 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION*2)> 

THEN 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET) >> 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL) 
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TRANSFORMATIONAL IMPLEMENTATION: 


CHANGES OUT OF STATE-B-3 


(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION B0ARD-P0SITI0N#2 BOARD-POSITION# 1 QUEEN#2 
QUEEN# 1 PIECE#2 PIECE# 1) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(RC.’OVE* QUEEN FROM QUEEN-SET) 

(FOR ALL (CHESS-BOARD BOARD-POSITION) 

THEREIS 

(IF (PIECE-ON-BOARD PIECE«2 BOARD-POSITION) 

THEN 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE 

NIL 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSlTIONn 
(IF (AND (PIECE-ON-BOARD QUEEN#2 B0ARD-P0SITI0N#2) 

(QUEEN-CAPTURE BOARD-POSITION B0ARD-P0SITI0N#2)) 

THEN 

(UNOO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL) 
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CHANGES INTO ST47E-5-5 


(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION BOARD-POSITION#2 BOARD-POSITION# 1 QUEEN.2 
QUEEN# 1 PIECE#2 PIECE# 1) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL (CHESS-BOARD BOARD-POSITION) 

THEREIS 

(IF (PIECE-ON-BOARD PIECE#2 BOARD-POSITION) 

THEN 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) > 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION) > 

(IF (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSITION*2> 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION#2>) 

THEN 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET) )> 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL: 






TRANSFORMATIONAL IMPLEMENTATION: 


CHANGES OUT OF STATE- 5-5 


tLAMBDA (QUEEN-SET > 

(LOCAL (QUEEN BOARD-POSITION B0ARD-P0SITI0N«2 BOARD-POSITION* 1 QUEEN«2 
QUEEN* 1 PIECE*2 PIECE* 1) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET> 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL (CHESS-BOARD BOARD-POSITION) 

THEREIS 

(IF (PIECE-ON-BOARD PIECE*2 BOARD-POSITION) 

THEN 

( LOOP-RETURN FORCE-ANOTHER-CHOICE > > 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSITION«2> 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION*2>> 

THEN 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET) >> 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL] 





AN EXAMPLE 
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CHANGES INTO STATES 


(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION BOARD-POSITION*2 BOARD-POSITION* 1 QUEEN*2 
QUEEN* 1 PIECE*2 PIECE* 1> 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET > 

(FOR ALL lAPAND (CHESS-BOARD BOARD-POSITION) 

(NOT (PIECE-ON-BOARD PIECE*2 BOARD-POSITION) 

THEREIS 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSITION*2> 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION*2)) 

THEN 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (OENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) > 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL) 







TRANSFORMATIONAL IMPLEMENTATION! 


CHANGES OUT OF STATES 


lLAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION B0ARD-P0SITI0N#2 BOARD-POSITION# 1 QUEEN«2 
QUEEN# 1 PIECE*2 PIECE# 1) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL 

(APAND (CHESS-BOARD BOARD-POSITION) 

(NOT (PIECE-ON-BOARD PIECE«2 BOARD-POSITION))) 

THEREIS 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (AND (PIECE-ON-BOARD QUEEN#2 BOARD-POSITION*2> 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION*2>> 

THEN 

( UNDO-ACTIONS : iDENY ( PIECE-ON-BOARD QUEEN 

BOARD-POSITION >)> 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE 

NIL) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL] 






AN EXAMPLE 
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CHANGES INTO STATE-S-1 


(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION B0ARD-P0SITI0N*2 BOARD-POSITION* 1 QUEEN*2 
QUEEN* 1 PIECE-2 PIECE* 1> 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL 

(APAND (CHESS-BOARD BOARD-POSITION) 

(NOT (PIECE-ON-BOARD PIECE*2 BOARD-POSITION))) 

THEREIS 

(IF (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSITION*2> 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION*2>> 

THEN 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE NIL) 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL) 
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TRANSFORMATIONAL IMPLEMENTATION: 


CHANGES OUT OF STATE-6-1 


I LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARO-POSITION BOARD-POSITIONS BOARD-POSITION* 1 QUEENS 
QUEEN* 1 PIECES PIECE* 1) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL 

(APAND (CHESS-BOARD BOARD-POSITION) 

(NOT (PIECE-ON-BOARD PIECES BOARD-POSITION))) 

THEREIS 

(IF (AND (PIECE-ON-BOARD QUEENS BOARD-POSITIONS) 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITIONS)) 

THEN 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) 

ELSE 

NIL 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (SUCCESSFUL (RECUPSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL) 
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CHANGES INTO STATE-6’3 


(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION BOARD-POSITION*2 BOARD-POSITION# 1 QUEEN*2 
QUEEN* 1 PIECE*2 PIECE* 1) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL 

(APAND (CHESS-BOARD BOARD-POSITION) 

(NOT (PIECE-ON-BOARD PIECE*2 BOARD-POSITION))) 

THEREIS 

(IF (AND (PIECE-ON-BOARD QUEEN-2 BOARD-POSITION*2) 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION*2) > 

THEN 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) > 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET) >> 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL] 


A. 
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TRANSFORMATIONAL IMPLEMENTATION* 


CHANGES OUT OF STATE-6‘3 


(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION B0ARD-P0SITI0N*2 BOARD-POSITION* 1 QUEEN*2 
QUEEN* 1 PIECE*2 PIECE* 1) 

(TERMINATION-TEST: (IF (EMPTY QU£EN-SET> 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL 

(APAND (CHESS-BOARD BOARD-POSITION) 

(NOT (PIECE-ON-BOARD PIECE»2 BOARD-POSITION))) 

THEREIS 

ilF (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSITION«2) 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION*2>) 

THEN 

tLOOP-RETURN FORCE-ANOTHER-CHOICE) > 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL) 


d 






AN EXAMPLE 
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CHANGES INTO STATES 


(LAMBDA (QUEE.'J-SET > 

(LOCAL (QUEEN BOARD-POSITION BOARD-POSITION*2 BOARD-POSITION# 1 QUEEN*2 
QUEEN* 1 PIECE*2 PIECE* 1> 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL 

lAPAND (APAND (CHESS-BOARD BOARD-POSITION) 

(NOT (PIECE-ON-BOARD PIECE*2 BOARD-POSITION) > 

) 

(NOT (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSlTION*2> 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITION*2) 

THEREIS 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET) » 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET) > 

(EXIT UNSUCCESSFUL) 



TRANSFORMATIONAL IMPLEMENTATION: 


CHANGES OUT OF STATE-6 


CLAMBOA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION B0ARD-P0SITI0N*2 BOARD-POSITION* 1 QUEEN*2 
QUEEN* 1 PIECE*2 PIECE* 1> 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL 

lAPAND lAPAND (CHESS-BOARD BOARD-POSITION) 

(NOT (PIECE-ON-BOARD PIECE«2 BOARD-POSITION) 

(NOT (AND (PIECE-ON-BOARD QUEEN*2 B0ARD-P0SITI0N*2) 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITlON*2) 

THEREIS 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN 

(EXIT SUCCESSFUL) 

ELf 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL) 










AN EXAMPLE 
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CHANGES INTO STATE-7 


tLAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION B0ARD-P0SIT!0N«2 BOARD-POSITION*1 QUEEN*2 
QUEEN* 1 PIECE*2 PIECE* 1) 

(ItRMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SETi 
(FOR ALL 

lAPAND (CHESS-BOARD BOARD-POSITION) 

(NOT (PIECE-ON-BOARD PIECE*2 BOARD-POSITION)) 

(NOT (AND (PIECE-ON-BOARD QUEEN*2 BOARD-POSITlON*2) 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITION*2) 

THEREIS 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) > 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL^ 
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TRANSFORMATIONAL IMPLEMENTATION: 


CHANGES OUT OF STATE-7 
(LAMBDA (QUEEN-SET) 

(LOCAL (QUEEN BOARD-POSITION B0ARD-P0SITI0N«2 BOARD-POSITION# 1 QUEEN*2 
QUEEN* 1 PIECE*2 PIECE* 1> 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN 

(EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR ALL 

(APAND ( CHESS-BOARD BOARD-POSITION) 

(NOT ( PIECE-ON-BOARD PIECEA2 BOARD-POSITION >> 

(NOT (AND i PIECE-ON-BOARD QUEENA2 BOARD-POSITION02> 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITION A2) 

THEREIS 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN 

(LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION))) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) > 

THEN 

(EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADD QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL) 







AN EXAMPLE 
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CHANGES INTO STATES 


tLAMBDA 

(QUEEN-SET POSSIBLE-BOARD-POSITIONS > 

(LOCAL (QUEEN BOARD-POSITION B0ARD-P0SIT10N*2 BOARD-POSITION# 1 QUEEN#2 QUEEN# 1 
PIECE*2 PIECE# 1) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) THEN (EXIT SUCCESSFUL))) 

(REMOVE* QUEFN FROM QUEEN-SET) 

(FOR ( BOARD-POSITION i IN-SET POSSIBLE-BOARD-POSITIONS THERElS 
(MAINTENANCE-ACTIONS: •FOR ALL 

(APAND ( CHESS-BOARD BOARD-POSITION > 

(NOT OlND ( PIECE-ON-BOARD QUEENA3 BOARD-POSITION A3) 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION#3 )> > 
(NOT < PIECE-ON-BOARD PIECEA2 BOARD-POSITION >>> 

LBIND (BOARD-POSITIONA3 QUEENA 3) 

DO (DELETE BOARD-POSITION FROM POSSIBLE-BOARD-POSITIONS n 
(FON 4LL 

(4P4ND (CHESS-BOARD BOARD-POSITION A3) 

(NOT (PIECE-ON-BOARD PIECEA3 BOARD-POSITION #3>> 
(QUEEN-CAPTURE BOARD-POSITION A3 BOARD-POSITION) 

(NOT (AND (PIECE-ON-BOARD QUEENA2 BOARD-POSITIONA2) 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION A2) 
LBIND (BOARD-POSITIONA3 PIECE# 3> 

DO (DELETE BOARD-POSITION A3 FROM POSSIBLE-BOARD-POSITIONS»> 

(ASSERT (PIECE-ON-BOARO QUEEN BOARD-POSITION)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN (LOOP-RETURN CHOICE-ACCEPTED) 

ELSE * 

(UNDO-ACTIONS: 

(DENY (PIECE-ON-BOARD QUEEN BOARD-POSITION) > 

(MAINTENANCE-ACTIONS: (FOR ALL 

(APAND (CHESS-BOARD BOARD-POSITION) 

(NOT (AND (PIECE-ON-BOARD QUEENA 3 BOARD-POSITION A3) 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITIONA 3»> 
(NOT (PIECE-ON-BOARD PIECEA2 BOARD-POSITION))) 

LBIND (BOARD-POSITIONA3 QUEENA3) 

DO (ADD BOARD-POSITION TO POSSIBLE-BOARD-POSITIONS)) 

(FOR ALL 

t APAND (CHESS-BOARD BOARD-POSITIONA3) 

(NOT (PIECE-ON-BOARD PIECE# 3 BOARD-POSITION A3) > 
(QUEEN-CAPTURE BOARD-POSITION A3 BOARD-POSITION) 

(NOT (AND (PIECE-ON-BOARD QUEENA2 BOARD-POSITIONA2) 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITIONA2 1 
LBIND (BOARD-POSITIONA3 PIECE# 3) 

00 (ADD BOARD-POSITION A3 TO POSSIBLE-BOARD-POSITIONS > 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN (EXIT SUCCESSFUL) 

ELSE (UNDO-ACTIONS: (ADO QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL) 






50 


TRANSFORMATIONAL IMPLEMENTATION: 


CHANGES OUT OF STATES 

(LAMBDA (QUEEN-SET POSSIBLE-BOARD-POSITIONS) 

(LOCAL (QUEEN BOARD-POSITION B0ARD-P0SITI0N*2 BOARD-POSITION* 1 QUEEN*2 
QUEEN* 1 PIECE*2 PIECE* 1) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) THEN (EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR (BOARD-POSITION) IN-SET POSSIBLE-BOARD-POSITIONS THEREIS 
(MAINTENANCE-ACTIONS: 

(FOR ALL (APAND < CHESS-BOARD BOARD-POSITION) 

(NOT (AND t PIECE-ON-BOARD QUEEN03 
BOARD-POSITION# 3> 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITION #3) > > 

(NOT (PIECE-ON-BOARD PIECE02 BOARD-POSITION > 
LBIND (BOARD-POSITION#3 QUEEN#3) DO 

(DELETE BOARD-POSITION FROM POSSIBLE-BOARD-POSITIONS 

(FOR ALL (APAND (CHESS-BOARD B0ARD-P0S!TI0N*3> 

(NOT (PIECE-ON-BOARD PIECE*3 B0ARD-P0SITI0N*3>> 

(QUEEN-CAPTURE B0ARD-P0SITI0N*3 BOARD-POSITION) 

(NOT (AND (PIECE-ON-BOARD QUEEN*2 B0ARD-P0SITI0N*2> 

(QUEEN-CAPTURE BOARD-POSITION B0ARD-P0SITI0N*2) 

LBIND (B0ARD-P0SITI0N*3 PIECE*3> 

DO (DELETE B0ARD-P0SITI0N*3 FROM POSSIBLE-BOARD-POSITIONS) 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN (LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: 

(DENY (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(MAINTENANCE-ACTIONS: 

(FOR ALL (APAND (CHESS-BOARD BOARD-POSITION > 

(NOT (AND (PIECE-ON-BOARD QUEEN03 
BOARD-POSITION #3) 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSIT I ON #3) > > 

(NOT (PIECE-ON-BOARD PIECE02 
BOARD-POSITION >>> 

LBIND (BOARD-POSITION#3 QUEEN03) DO 

(ADD BOARD-POSITION TO POSSIBLE-BOARD-POSITIONS )> 

(FOR ALL (APAND (CHESS-BOARD B0ARD-P0SITI0N*3> 

(NOT (PIECE-ON-BOARD PIECE*3 B0ARD-P0SITI0N*3>) 

(QUEEN-CAPTURE B0ARD-P0SITI0N*3 BOARD-POSITION) 

(NOT (AND (PIECE-ON-BOARD QUEEN*2 B0ARD-P0SITI0N*2> 

(QUEEN-CAPTURE BOARD-POSITION BOARD-POSITION*2J 
LBIND (BOARD-POSITIONS PIECE*3) 

00 (ADD B0ARD-P0SITI0N*3 TO POSSIBLE-BOARD-POSITIONS) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN (EXIT SUCCESSFUL) 

ELSE (UNDO-ACTIONS: (ADO QUEEN TO QUEEN-SETn 
(EXIT UNSUCCESSFUL) 


J 






CHANGES INTO STATE-9 


(LAMBDA (QUEEN-SET POSSIBLE-BOARD-POSITIONS) 

(LOCAL (QUEEN BOARD-POSITION B0ARD-P0SITI0N#2 BOARD-POSITION# 1 QUEEN#2 
QUEEN# 1 PIECE#2 PIECE# 1) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN (EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR (BOARD-POSITION) IN-SET POSSIBLE-BOARD-POSITIONS 
THEREIS 

(MAINTENANCE-ACTIONS: 

(FOR ALL 

(APAND (CHESS-BOARD BOARD-POSITION#3> 

(NOT (PIECE-ON-BOARD PIECE#3 B0ARD-P0SITI0N#3>> 
(QUEEN-CAPTURE BOARD-POSITION-3 
BOARD-POSITION) 

(NOT (AND (PIECE-ON-BOARD QUEEN«2 

BOARD-POSITION#2> 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITION#2) 

LBIND (B0ARD-P0SITI0N#3 PIECE#3) 

DO (DELETE BOARD-POSITION#3 FROM 
POSSIBLE-BOARD-POSITIONS) 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET))) 

THEN (LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: 

(DENY (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 
(MAINTENANCE-ACTIONS: 

(FOR ALL 

(APAND (CHESS-BOARD B0ARD-P0SITI0N#3) 

(NOT (PIECE-ON-BOARD PIECE#3 

BOARD-POSITION*3>> 
(QUEEN-CAPTURE B0ARD-P0SITI0N«3 
BOARD-POSITION) 

(NOT (AND (PIECE-ON-BOARD QUEEN#2 
BOARD-POSITION#2) 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITtON#2l 
LBIND (BOARD-POSITION#3 PIECE#3) 

DO 

(ADD BOARD-POSITION#3 TO 
POSSIBLE-BOARD-POSITIONSJ 
(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN (EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADO QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUj 






TRANSFORMATIONAL IMPLEMENTATION: 


CHANGES OUT OF STATE-9 


(LAMBDA 

< QUEEN-SET POSSIBLE-BOARD-POSITIONS > 

(LOCAL 

(QUEEN BOARD-POSITION B0ARD-P0SITI0N«2 BOARD-POSITION* 1 QUEEN*2 QUEEN* 1 
PIECE*2 PIECE* 1) 

(TERMINATION-TEST: (IF (EMPTY QUEEN-SET) 

THEN (EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SET) 

(FOR (BOARD-POSITION) IN-SET POSSIBLE-BOARD-POSITIONS 
THEREIS 

(MAINTENANCE-ACTIONS: (FOR ALL 

lAPAND ( CHESS-BOARD BOARD-POSITION#3) 
iNOT < PIECE-ON-BOARD PIECE03 

BOARD-POSITION# 3> > 

( QUEEN-CAPTURE BOARD-POSITION#3 
BOARD-POSITION) 

(NOT (AND ( PIECE-ON-BOARD QUEEN#2 
B0ARD-P0SITI0N#2) 

( QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSITION#2 j 
LBIND (BOARD-POSITION#3 PIECE#3) 

DO 

(DELETE BOARD-POSITION#3 FROM 
POSSIBLE-BOARD-POSITIONS) > > 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET ) 

THEN (LOOP-RETURN CHOICE-ACCEPTED) 

ELSE 

(UNDO-ACTIONS: 

(DENY (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(MAINTENANCE-ACTIONS: (FOR ALL 

lAPAND (CHESS-BOARD BOARD-POSITION#3) 
iNOT (PIECE-ON-BOARD PIECE#3 
BOARD-POSITION# 3>> 
(QUEEN-CAPTURE BOARD-POSITION#3 
BOARD-POSITION > 

(NOT (AND (PIECE-ON-BOARD QUEEN#2 
BOARD-POSITION #2) 
(QUEEN-CAPTURE BOARD-POSITION 
BOARD-POSIT I ON #2\ 

LBIND (BOARD-POSITION#3 PIECE#3) 

DO 

(ADD BOARD-POSITION#3 TO 
POSSIBLE-BOARD-POSITIONS) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE) > 

THEN (EXIT SUCCESSFUL) 

ELSE 

(UNDO-ACTIONS: (ADO QUEEN TO QUEEN-SET) > 

(EXIT UNSUCCESSFUL) 




CHANGES INTO STATE-10 


(LAMBDA < QUEEN-SET REMAINING-ROWS REMAINING-COLUMNS 

REM AINING-NE-DI AGON ALS REM AINING-SE-DI AGON ALS) 

(LOCAL (QUEEN BOARD-POSITION B0ARD-P0SITI0N*2 BOARD-POSITION* 1 QUEEN*2 
QUEEN* 1 PIECE*2 PIECE* 1) 

(TERMINATION-TEST: <IF (EMPTY QUEEN-SET) 

THEN (EXIT SUCCESSFUL))) 

(REMOVE* QUEEN FROM QUEEN-SETi 
ci FOR ROW IN-SET REMAINING-ROWS THEREIS 
(FOR COLUMN IN-SET REMAINING-COLUMNS 
WHEN 

(PROGN ( DETERMINE* NE-DIAGONAL FROM 

(CORRESPONDING-NE-DAGONAL ROW COLUMN » 
DETERMINE* SE-DIAGONAL FROM 

(CORRESPOND! NG-SE-DI AGONAL ROW COLUMN >) 

(APAND (IN-SET? NE-DIAGONAL REM AINING-NE-DI AGON ALS) 
(IN-SET? SE-DIAGONAL REM AINING-SE-DI AGON ALS) 
n 

THEREIS 

(MAINTENANCE-ACTIONS: < REMOVE* AOIV FROM REMAINING-ROWS) 
(REMOVE* COLUMN FROM 

REMAINING-COLUMNS) 

(REMOVE* NE-DIAGONAL FROM 

REM AINING-NE-DI AGON ALS) 

(REMOVE* SE-DIAGONAL FROM 

REM AINING-SE-DI AGON ALS) > 

(DETERMINE* BOARD-POSITION FROM 

(C ORRE SPONDING-BOARD-POSITI ON BOARD-POSITION 

ROW COLUMN)) 

(ASSERT (PIECE-ON-BOARD QUEEN BOARD-POSITION)) 

(IF (SUCCESSFUL (RECURSIVE-CALL: (QUEENS QUEEN-SET 

REMAINING-ROWS 
REMAINING-COLUMNS 
REM AINING-NE-DI AGON ALS 
REM AINING-SE-DI AGON ALS) 

THEN (LOOP-RETURN CHOICE-ACCEPTED) 

ELSE (UNDO-ACTIONS: (DENY (PIECE-ON-BOARD QUEEN 

BOARD-POSITION)) 

(MAINTENANCE-ACTIONS: (ADD ROW TO 
REMAINING-ROWS) 

(ADD COLUMN TO 
REMAINING-COLUMNS) 

(ADD NE-DIAGONAL TO 
REMAINING-NE-DIAGONALS) 

(ADD SE-DIAGONAL TO 
REM AIN I NG-SE-DI AGON ALS) 

(LOOP-RETURN FORCE-ANOTHER-CHOICE)) 

THEN (EXIT SUCCESSFUL) 

ELSE (UNDO-ACTONS: (ADO QUEEN TO QUEEN-SET)) 

(EXIT UNSUCCESSFUL] 
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